Expand description
Rustls - a modern TLS library
Rustls is a TLS library that aims to provide a good level of cryptographic security, requires no configuration to achieve that security, and provides no unsafe features or obsolete cryptography.
Current features
- TLS1.2 and TLS1.3.
- ECDSA, Ed25519 or RSA server authentication by clients.
- ECDSA, Ed25519 or RSA server authentication by servers.
- Forward secrecy using ECDHE; with curve25519, nistp256 or nistp384 curves.
- AES128-GCM and AES256-GCM bulk encryption, with safe nonces.
- ChaCha20-Poly1305 bulk encryption (RFC7905).
- ALPN support.
- SNI support.
- Tunable fragment size to make TLS messages match size of underlying transport.
- Optional use of vectored IO to minimise system calls.
- TLS1.2 session resumption.
- TLS1.2 resumption via tickets (RFC5077).
- TLS1.3 resumption via tickets or session storage.
- TLS1.3 0-RTT data for clients.
- TLS1.3 0-RTT data for servers.
- Client authentication by clients.
- Client authentication by servers.
- Extended master secret support (RFC7627).
- Exporters (RFC5705).
- OCSP stapling by servers.
- SCT stapling by servers.
- SCT verification by clients.
Possible future features
- PSK support.
- OCSP verification by clients.
- Certificate pinning.
Non-features
For reasons explained in the manual, rustls does not and will not support:
- SSL1, SSL2, SSL3, TLS1 or TLS1.1.
- RC4.
- DES or triple DES.
- EXPORT ciphersuites.
- MAC-then-encrypt ciphersuites.
- Ciphersuites without forward secrecy.
- Renegotiation.
- Kerberos.
- Compression.
- Discrete-log Diffie-Hellman.
- Automatic protocol version downgrade.
There are plenty of other libraries that provide these features should you need them.
Platform support
Rustls uses ring
for implementing the
cryptography in TLS. As a result, rustls only runs on platforms
supported by ring
.
At the time of writing this means x86, x86-64, armv7, and aarch64.
Design Overview
Rustls does not take care of network IO
It doesn’t make or accept TCP connections, or do DNS, or read or write files.
There’s example client and server code which uses mio to do all needed network IO.
Rustls provides encrypted pipes
These are the ServerConnection
and ClientConnection
types. You supply raw TLS traffic
on the left (via the read_tls()
and write_tls()
methods) and then read/write the
plaintext on the right:
TLS Plaintext
=== =========
read_tls() +-----------------------+ reader() as io::Read
| |
+---------> ClientConnection +--------->
| or |
<---------+ ServerConnection <---------+
| |
write_tls() +-----------------------+ writer() as io::Write
Rustls takes care of server certificate verification
You do not need to provide anything other than a set of root certificates to trust. Certificate verification cannot be turned off or disabled in the main API.
Getting started
This is the minimum you need to do to make a TLS client connection.
First we load some root certificates. These are used to authenticate the server.
The recommended way is to depend on the webpki_roots
crate which contains
the Mozilla set of root certificates.
let mut root_store = rustls::RootCertStore::empty();
root_store.add_server_trust_anchors(
webpki_roots::TLS_SERVER_ROOTS
.0
.iter()
.map(|ta| {
rustls::OwnedTrustAnchor::from_subject_spki_name_constraints(
ta.subject,
ta.spki,
ta.name_constraints,
)
})
);
Next, we make a ClientConfig
. You’re likely to make one of these per process,
and use it for all connections made by that process.
let config = rustls::ClientConfig::builder()
.with_safe_defaults()
.with_root_certificates(root_store)
.with_no_client_auth();
Now we can make a connection. You need to provide the server’s hostname so we know what to expect to find in the server’s certificate.
let rc_config = Arc::new(config);
let example_com = "example.com".try_into().unwrap();
let mut client = rustls::ClientConnection::new(rc_config, example_com);
Now you should do appropriate IO for the client
object. If client.wants_read()
yields
true, you should call client.read_tls()
when the underlying connection has data.
Likewise, if client.wants_write()
yields true, you should call client.write_tls()
when the underlying connection is able to send data. You should continue doing this
as long as the connection is valid.
The return types of read_tls()
and write_tls()
only tell you if the IO worked. No
parsing or processing of the TLS messages is done. After each read_tls()
you should
therefore call client.process_new_packets()
which parses and processes the messages.
Any error returned from process_new_packets
is fatal to the connection, and will tell you
why. For example, if the server’s certificate is expired process_new_packets
will
return Err(WebPkiError(CertExpired, ValidateServerCert))
. From this point on,
process_new_packets
will not do any new work and will return that error continually.
You can extract newly received data by calling client.reader()
(which implements the
io::Read
trait). You can send data to the peer by calling client.writer()
(which
implements io::Write
trait). Note that client.writer().write()
buffers data you
send if the TLS connection is not yet established: this is useful for writing (say) a
HTTP request, but this is buffered so avoid large amounts of data.
The following code uses a fictional socket IO API for illustration, and does not handle errors.
use std::io;
use rustls::Connection;
client.writer().write(b"GET / HTTP/1.0\r\n\r\n").unwrap();
let mut socket = connect("example.com", 443);
loop {
if client.wants_read() && socket.ready_for_read() {
client.read_tls(&mut socket).unwrap();
client.process_new_packets().unwrap();
let mut plaintext = Vec::new();
client.reader().read_to_end(&mut plaintext).unwrap();
io::stdout().write(&plaintext).unwrap();
}
if client.wants_write() && socket.ready_for_write() {
client.write_tls(&mut socket).unwrap();
}
socket.wait_for_something_to_happen();
}
Examples
tlsserver
and tlsclient
are full worked examples. These both use mio.
Crate features
Here’s a list of what features are exposed by the rustls crate and what they mean.
-
logging
: this makes the rustls crate depend on thelog
crate. rustls outputs interesting protocol-level messages attrace!
anddebug!
level, and protocol-level errors atwarn!
anderror!
level. The log messages do not contain secret key data, and so are safe to archive without affecting session security. This feature is in the default set. -
dangerous_configuration
: this feature enables adangerous()
method onClientConfig
andServerConfig
that allows setting inadvisable options, such as replacing the certificate verification process. Applications requesting this feature should be reviewed carefully. -
quic
: this feature exposes additional constructors and functions for using rustls as a TLS library for QUIC. See thequic
module for details of these. You will only need this if you’re writing a QUIC implementation. -
tls12
: enables support for TLS version 1.2. This feature is in the default set. Note that, due to the additive nature of Cargo features and because it is enabled by default, other crates in your dependency graph could re-enable it for your application. If you want to disable TLS 1.2 for security reasons, consider explicitly enabling TLS 1.3 only in the config builder API. -
read_buf
: When building with Rust Nightly, adds support for the unstablestd::io::ReadBuf
and related APIs. This reduces costs from initializing buffers. Will do nothing on non-Nightly releases.
Re-exports
pub use client::ClientConfig;
pub use client::ClientConnection;
pub use client::ServerName;
pub use server::ServerConfig;
pub use server::ServerConnection;
Modules
- All defined ciphersuites appear in this module.
- Items for use in a client.
- Internal classes which may be useful outside the library. The contents of this section DO NOT form part of the stable interface.
- All defined key exchange groups appear in this module.
- This is the rustls manual.
- quic
quic
APIs for implementing QUIC TLS - Items for use in a server.
- Message signing interfaces and implementations.
- All defined protocol versions appear in this module.
Structs
- This type contains a single certificate by value.
- Connection state common to both client and server connections.
- Building a
ServerConfig
orClientConfig
in a linker-friendly and complete way. - Interface shared by client and server connections.
- Secrets for transmitting/receiving data over a TLS session.
- Values of this structure are returned from
Connection::process_new_packets
and tell the caller the current I/O state of the TLS connection. KeyLog
implementation that opens a file whose name is given by theSSLKEYLOGFILE
environment variable, and writes keys into it.- KeyLog that does exactly nothing.
- A trust anchor, commonly known as a “Root Certificate.”
- This type contains a private key by value.
- A structure that implements
std::io::Read
for reading plaintext. - A container for root certificates able to provide a root-of-trust for connection authentication.
- This type implements
io::Read
andio::Write
, encapsulating a ConnectionC
and an underlying transportT
, such as a socket. - This type implements
io::Read
andio::Write
, encapsulating and owning a ConnectionC
and an underlying blocking transportT
, such as a socket. - A key-exchange group supported by rustls.
- A TLS protocol version supported by rustls.
- A concrete, safe ticket creation mechanism.
- A TLS 1.2 cipher suite supported by rustls.
- A TLS 1.3 cipher suite supported by rustls.
- Config builder state where the caller must supply cipher suites.
- Config builder state where the caller must supply key exchange groups.
- Config builder state where the caller must supply a verifier.
- Config builder state where the caller must supply TLS protocol versions.
- A structure that implements
std::io::Write
for writing plaintext.
Enums
- The
AlertDescription
TLS protocol enum. Values in this enum are taken from the various RFCs covering TLS, and are listed by IANA. TheUnknown
item is used when processing unrecognised ordinals. - Bulk symmetric encryption scheme used by a cipher suite.
- The
CipherSuite
TLS protocol enum. Values in this enum are taken from the various RFCs covering TLS, and are listed by IANA. TheUnknown
item is used when processing unrecognised ordinals. - A client or server connection.
- Secrets used to encrypt/decrypt data in a TLS session.
- The
ContentType
TLS protocol enum. Values in this enum are taken from the various RFCs covering TLS, and are listed by IANA. TheUnknown
item is used when processing unrecognised ordinals. - rustls reports protocol errors using this type.
- The
HandshakeType
TLS protocol enum. Values in this enum are taken from the various RFCs covering TLS, and are listed by IANA. TheUnknown
item is used when processing unrecognised ordinals. - The
NamedGroup
TLS protocol enum. Values in this enum are taken from the various RFCs covering TLS, and are listed by IANA. TheUnknown
item is used when processing unrecognised ordinals. - The
ProtocolVersion
TLS protocol enum. Values in this enum are taken from the various RFCs covering TLS, and are listed by IANA. TheUnknown
item is used when processing unrecognised ordinals. - The
SignatureAlgorithm
TLS protocol enum. Values in this enum are taken from the various RFCs covering TLS, and are listed by IANA. TheUnknown
item is used when processing unrecognised ordinals. - The
SignatureScheme
TLS protocol enum. Values in this enum are taken from the various RFCs covering TLS, and are listed by IANA. TheUnknown
item is used when processing unrecognised ordinals. - A cipher suite supported by rustls.
Statics
- A list of all the cipher suites supported by rustls.
- A list of all the key exchange groups supported by rustls.
- A list of all the protocol versions supported by rustls.
- The cipher suite configuration that an application should use by default.
- The version configuration that an application should use by default.
Traits
- This trait represents the ability to do something useful with key material, such as logging it to a file for debugging.
- Data specific to the peer’s side (client or server).
Type Aliases
- DistinguishedNames is a
Vec<Vec<u8>>
wrapped in internal types. Each element contains the DER or BER encodedSubject
field from RFC 5280 for a single certificate. The Subject field is encoded as an RFC 5280Name
. It can be decoded using x509-parser’s FromDer trait.